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Inverse Address Resolution Protocol 
1. Status of this Memo 


This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


2. Abstract 


This memo describes additions to ARP that will allow a station to 
request a protocol address corresponding to a given hardware address. 
Specifically, this applies to Frame Relay stations that may have a 
Data Link Connection Identifier (DLCI), the Frame Relay equivalent of 
a hardware address, associated with an established Permanent Virtual 
Circuit (PVC), but do not know the protocol address of the station on 
the other side of this connection. It will also apply to other 
networks with similar circumstances. 


3. Conventions 


The following language conventions are used in the items of 
specification in this document: 


o Must, Will, Shall or Mandatory -- the item is an absolute 
requirement of the specification. 


o Should or Recommended -- the item should generally be 
followed for all but exceptional circumstances. 


o May or Optional -- the item is truly optional and may be 
followed or ignored according to the needs of the 
implementor. 

4. Introduction 


This document will rely heavily on Frame Relay as an example of how 
the Inverse Address Resolution Protocol (InARP) can be useful. It is 
not, however, intended that InARP be used exclusively with Frame 
Relay.  InARP may be used in any network that provides destination 
hardware addresses without indicating corresponding protocol 
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addresses. 
5. Motivation 


The motivation for the development of Inverse ARP is a result of the 
desire to make dynamic address resolution within Frame Relay both 
possible and efficient. Permanent virtual circuits (PVCs) and 
eventually switched virtual circuits (SVCs) are identified by a Data 
Link Connection Identifier (DLCI). These DLCIs define a single 
virtual connection through the wide area network (WAN) and are the 
Frame Relay equivalent to a hardware address. Periodically, through 
the exchange of signalling messages, a network may announce a new 
virtual circuit with its corresponding DLCI. Unfortunately, protocol 
addressing is not included in the announcement. The station 
receiving such an indication will learn of the new connection, but 
will not be able to address the other side. Without a new 
configuration or mechanism for discovering the protocol address of 
the other side, this new virtual circuit is unusable. 


Other resolution methods were considered to solve the problems, but 
were rejected. Reverse ARP [4], for example, seemed like a good 
candidate, but the response to a request is the protocol address of 
the requesting station not the station receiving the request as we 
wanted. IP specific mechanisms were limiting since we wished to 
allow protocol address resolution of many protocols. For this 
reason, we expanded the ARP protocol. 


Inverse Address Resolution Protocol (InARP) will allow a Frame Relay 
station to discover the protocol address of a station associated with 
the virtual circuit. It is more efficiently than simulating a 
broadcast with multiple copies of the same message and it is more 
flexible than relying on static configuration. 


6. Packet Format 


Inverse ARP is an extension of the existing ARP. Therefore, it has 
the same format as standard ARP. 


arShrd 16 bits Hardware type 

arSpro 16 bits Protocol type 

arShin 8 bits Byte length of each hardware address (n) 
arSplin 8 bits Byte length of each protocol address (m) 
arSop 16 bits Operation code 

arSsha nbytes source hardware address 

arSspa mbytes source protocol address 

arStha nbytes target hardware address 

arStpa mbytes target protocol address 
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Possible values for hardware and protocol types are the same as those 
for ARP and may be found in the current Assigned Numbers RFC [2]. 


Length of the hardware and protocol address are dependent on the 
environment in which InARP is running. For example, if IP is running 
over Frame Relay, the hardware address length is between 2 and 4, and 
the protocol address length is 4. 


The operation code indicates the type of message, request or reply. 


InARP request = 8 
InARP reply = 9 


These values were chosen so as not to conflict with other ARP 
extensions. 


7. Protocol Operation 


Basic InARP operates essentially the same as ARP with the exception 
that InARP does not broadcast requests. This is because the hardware 
address of the destination station is already known. A requesting 
station simply formats a request by inserting its source hardware and 
protocol addresses and the known target hardware address. It then 
zero fills the target protocol address field. Finally, it will 
encapsulate the packet for the specific network and send it directly 
to the target station. 


Upon receiving an InARP request, a station may put the requester’s 
protocol address/hardware address mapping into its ARP cache as it 
would any ARP request. Unlike other ARP requests, however, the 
receiving station may assume that any InARP request it receives is 
destined for it. For every InARP request, the receiving station may 
format a proper reply using the source addresses from the request as 
the target addresses of the reply. If the station is unable or 
unwilling to reply, it ignores the request. 


When the requesting station receives the InARP reply, it may complete 
the ARP table entry and use the provided address information. Note: 
as with ARP, information learned via InARP may be aged or invalidated 
under certain circumstances. 


7.1. Operation with Multi-Addressed Hosts 


In the context of this discussion, a Multi-Addressed host will refer 
to a host that has multiple protocol addresses assigned to a single 
interface. If such a station receives an InARP request, it must 
choose one address with which to respond. To make such a selection, 
the receiving station must first look at the protocol address of the 
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requesting station, and then respond with the protocol address 
corresponding to the network of the requester. For example, if the 
requesting station is probing for an IP address, the responding 
multi-addressed station should respond with an IP address which 
corresponds to the same subnet as the requesting station. If the 
station does not have an address that is appropriate for the request 
it should not respond. In the IP example, if the receiving station 
does not have an IP address assigned to the interface that is a part 
of the requested subnet, the receiving station would not respond. 


A multi-addressed host may choose to send an InARP request for each 
of the addresses defined for the given interface. It should be 
noted, however, that the receiving side may answer some or none of 
the requests depending on its configuration. 


7.2. Protocol Operation Within Frame Relay 


One case where Inverse ARP can be used is when a new virtual circuit 
is signalled. The Frame Relay station may format an InARP request 


addressed to the new virtual circuit. If the other side supports 
InARP, it may return a reply indicating the protocol address 
requested. 


The format for an InARP request is a follows: 


arShrd - 0x000F the value assigned to Frame Relay 

arSpro - protocol type for which you are searching 
(i.e. IP = 0x0800) 

arShin - 2,3, or 4 byte addressing length 

arSpln - byte length of protocol address for which you 
are searching (for IP = 4) 

arSop - 8; InARP request 

arSsha - Q.922 address of requesting station 

arSspa - protocol address of requesting station 

arStha - Q.922 addressed of newly announced virtual circuit 

arStpa - 0; This is what we’re looking for 
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The InARP response will be completed similarly. 


arShrd - 0x000F the value assigned to Frame Relay 

arSpro - protocol type for which you are searching 
(i.e. IP = 0x0800) 

arShln - 2,3, or 4 byte addressing length 

arSpln - byte length of protocol address for which you 
are searching (for IP = 4) 

arSop - 9; InARP response 

arSsha - Q.922 address of responding station 

arSspa - protocol address requested 

arStha - Q.922 address of requesting station 

arStpa - protocol address of requesting station 


Note that the Q.922 addresses specified have the C/R, FECN, BECN, and 
DE bits set to zero. 


Procedures for using InARP over a Frame Relay network are identical 
to those for using ARP and RARP discussed in section 10 of the 
Multiprotocol Interconnect over Frame Relay Networks document [3]. 
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9. Security Considerations 


Security issues are not addressed in this memo. 
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